Bump bant dev dependency 0.2.4 → 0.2.5#10102
Conversation
dev_dependency=True, not propagated to downstream consumers. verilator, rules_scala, and rules_jvm_external were not upgraded due to tight coupling in the Scala/Chisel/Verilator ecosystem that requires a coordinated upgrade effort. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
|
clang-tidy review says "All clean, LGTM! 👍" |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the 'bant' development dependency to version 0.2.5 in the MODULE.bazel file and synchronizes the MODULE.bazel.lock file. The lock file updates include version increments for apple_support, pybind11_bazel, and re2, the addition of bazel_features and rules_python versions, and the removal of a rules_cc entry. I have no feedback to provide.
|
@hzeller Good idea to upgrade? |
|
yeah, keeping that fresh is always good. |
|
update lock |
@hzeller The pain! Proposal: Move lint, format, and MODULE.bazel.lock updates to post-merge commits As an external contributor and maintainer contact, I'd like to raise a CI policy concern that is creating significant and avoidable serialization overhead for anyone submitting multiple independent PRs that touch MODULE.bazel. The current workflow requires a "update lock" step that can only be completed after the daily pr-merge bump runs — a 1–2 day gate per PR. Since any number of open PRs touching MODULE.bazel will conflict with each other, they cannot be merged in parallel. Each must be merged, verified clean, and only then can the next be rebased and queued. Across N PRs, this compounds into weeks of wall-clock time for what are often routine, independent changes. The proposed fix: remove linting, formatting, and MODULE.bazel.lock update requirements from PR checks entirely, and instead apply them automatically in a post-merge commit via CI. This is the same approach we adopted internally after hitting this exact wall, and GitHub merge queues make it straightforward to implement cleanly. On the security question: I anticipate a concern that removing the lock file check from PRs weakens security. I'd argue the opposite. The MODULE.bazel.lock file is auto-generated — a malicious PR doesn't need to manipulate it directly, only MODULE.bazel itself, which human review should catch regardless. More importantly, a lock file generated by a controlled, auditable CI environment after merge is more trustworthy than one generated on a contributor's local machine, which may be compromised or misconfigured. The meaningful security surface is the dependency change in MODULE.bazel, not the generated lock. Removing this check from PRs reduces friction for legitimate contributors, eliminates a serialization bottleneck that disproportionately impacts high-volume contribution workflows, and arguably improves the integrity of the generated lock file. And while we are at it — please, the lint, gemini nags and format checks too. We are begging. Every contributor has been there: the code is correct, the change is good, the review is done — and it sits blocked because a line is two spaces wide instead of one, or because the local clang-format version is 14.0.1 instead of 14.0.0. It is death by a thousand papercuts. Auto-applying lint and format in a post-merge commit costs nothing and gives back enormous amounts of contributor goodwill, maintainer time, and CI throughput. The codebase stays clean. The pain goes away. 🥺 |
|
I made the mistake of adding bazel lock |
3 participants
dev_dependency=True, not propagated to downstream consumers.
verilator, rules_scala, and rules_jvm_external were not upgraded due to tight coupling in the Scala/Chisel/Verilator ecosystem that requires a coordinated upgrade effort.